大概敘述一下在系統整合廠的軟體流程的規劃, 我所敘述的不一定是最好的流程. 但拋磚引玉給大家參考.
軟體開發流程是門大學問, 這也是我們在學校裡面學的軟體工程的主軸, 從傳統的Waterfall 模型, 到XP (Extreme programming), Scrum 等等, 在CMMI和古老的SDG中也有它定義的軟體開發流程. 每種理論都有它的道理在, 而在不同流程中, 也都會有它定義的角色和負責的工作. 採用哪套流程比較好? 我想沒有絕對的答案. 最好的流程就是為自己打造一個適合自己團隊的流程. 它可能是Waterfall 的方式, 可能是 Scrum 的方式, 也可能什麼都不是. 但是定義出屬於團隊的流程是很重要的. 有了這個流程, 團隊才能循著這個軌道不斷的運行下去.

有許多純軟體的公司他們有很好的軟體開發流程, 他們有專業的專案經理, 系統分析師, 系統設計師, 軟體工程師, 軟體測試等角色分工, 每個人也都知道自己該負責的工作範圍, 也有定義很清楚的軟體流程, 因此從時程規畫, 需求分析, 設計, 撰寫程式, 測試到軟體發行, 大家都很清楚自己該在什麼時候做什麼事, 寫什麼文件. 但在台灣的科技產業, 長久以來是以硬體為主力, 所以在硬體為主的公司, 軟體流程往往是比較被忽略的. 因此在此分享一下在系統整合廠, 我們的軟體流程是怎麼個規畫的, 以及一些考量的點.

一般系統整合廠的時程是以工廠生產為中心, 所以對整個專案而言是以硬體版本為主, 版本大概分為Evaluation Sample (ES), System integrated Sample (SI), Development Sample (DV), Pre-release Sample (PV), Mass release (MP). 以上只是舉例，每家公司的定義都會有差異, 所以雖然傳統上軟體會有所謂的版號(Major, minor number, build number) 還有Alpha, Beta, Release Candidate, 正式版等等, 但是這些版本跟專案的Schedule 很難扯上關係, 所以軟體版本和Schedule 要如何和Project 搭上關係呢? 我想留到後面的單元再來詳述. 這個單元我就聚焦在一個軟體版本的Cycle內, 軟體流程的規劃.

正常的軟體開發流程, 可以從RFI (Request for Information)/RFP (Request for Proposal )/RFQ (Request for Quotation) 開始, 這部分就類似做標案取得招標說明, 弄懂標案規格, 寫投標書一樣, 從這時候軟體人員就要參與, 看看規格內的需求軟體是不是可以達到, 然後初估一下時程 (這要根據經驗) 看能不能在要求時間內完成. 不過有很多客戶, 或是自有品牌公司的產品在初期對於軟體的規格是沒什麼概念的, 他可能只會定義作業系統要用哪套, 其他的就是硬體規格為主. 所以軟體團隊就要有個很有經驗的人, 跟軟體專案經理(如果有的話) 協力去完成這項任務.

通常軟體規格除了應用程式之外都是跟硬體綁在一塊 (作業系統和驅動程式部分), 因此從硬體開出的Key part, 其實也大概可以寫出粗略的軟體規格, 然後再加上應用程式部分, 就可以寫出第一份的軟體規格書. 為什麼強調要有軟體規格書呢? 因為我認為比較好的軟體開發流程, 應該要跟一般純軟體的開發一樣, 有所謂的系統分析, 系統設計, 軟體撰寫, 單元測試 , 整合測試, 軟體發行 這幾個階段, 但一般硬體廠一方面有時程壓力, 一方面不重視軟體流程, 所以很少會有編制專門的系統分析師, 系統設計師. 要不就是東西拿到就開始低頭寫程式, 要不就是專案經理開出一份很粗略的規格, 也有公司是要求程式設計員兼著寫規格文件的, 但是常常都是先開發完才補文件. 但這樣的結果就會造成很多設計上的問題, 往往在產品中後段才會發現, 可是已經為時已晚. 因此我建議團隊裡面要有個資深的人員, 負責撰寫軟體規格書, 然後再從軟體規格書去細分出每個模組(如Bootloader, SD, Wifi, BT, USB 或應用程式 等等), 再由負責開發模組的工程師撰寫設計文件(Design Document), 等設計文件寫出來之後, 再根據設計文件去完成每個驅動程式, 應用程式的開發.

當軟韌體開發出來後, 每個工程師都要先做好單元測試, 有些公司會有專門的測試人員來進行, 但我建議測試人員應該放在整合之後再做測試, 整合前的測試最好還是工程師自己進行, 一方面工程師比較知道自己改了些什麼, 另一方面也是代表對自己寫的程式負責任的態度 (整合出來的Image有問題不要怪測試人員沒幫你測出來, 因為都是自己測的). 另外如果改的程式碼會影響到別人, 也要找相關人員先做好整合測試, 都沒問題後再將程式上傳到Source code control server 上 (不管用哪一套都可以), 上傳完成後就可以進行整合, 由整合的人員將Image 產生出來, 然後再交由測試人員進行單元測試和整合測試, 都通過測試之後才正式發行版本.

以上是從專案開始到一個版本產生的軟體開發流程, 寫得非常亂, 所以我再整理一次如下: 客戶提出需求->根據需求提出建議書->客戶同意後,撰寫軟體規格書->軟體規格書往下分解成各個模組->撰寫設計文件->開發軟韌體->單元測試->整合,產生Image->單元測試+整合測試->發行版本.

PS1: 整個流程, 要搭配許多工具來完成, 包含Source code control Server, Bug Tracking System, file server 等等, 最好還有一套 Project Management System 來統合從頭到尾的流程, 未來也會介紹一些好用且免錢的軟體, 彼此之間可以串起來完成以上任務. (當然有錢的公司也可以買微軟的TFS 配上開發工具, 或是整套的Rational 產品來完成.)

PS2:為確保軟體的品質, 除了定期的版本發行外, 建議也要做Daily build. 確保每天工程師進的程式碼都是沒問題的 (至少沒有Compiler error), 另外還可以做Code review, 詳細做法未來再詳述.